Embodiments relate generally to a method for visually modeling screen-flows. Embodiments relate further to a portal application development system, a computing system, a data processing program, and a computer program product.
Customers often have to implement portal/portlet based solutions that guide users through a well-defined sequence of screens. These sequences route users along paths which interconnect user interface (UI) artifacts (forms, masks, etc.) that, altogether, allow them to easily accomplish particular tasks. From a user perspective, stepping through such sequences feels like navigating with wizards. It relieves users from thinking about the right order of navigation and processing of screens.
The need for such solutions arises across all vertical industries. E.g., in the insurance sector, screen-flow modelers might need to model flows for processing policy quotes or claim submissions. In particular, quoting a vehicle insurance policy may be comprised of steps like vehicle selection, vehicle data specification, insurance data collection, tariff characteristics selection, and so forth. Similar applications can be thought of when thinking of banking, help desks, or travel booking applications.
When developing portal based solutions, screens (in other words functions) are usually provided by portlets. But the mapping of individual screens to portlets is often not trivial since it has impact on both user experience as well as reusability.
Users have typically had to pick between two extremes. On the one hand, they can decide to let one single portlet provide all necessary screens (and thus, the entire set of functions needed to accomplish a particular task). On the other hand, they can decide to develop one dedicated portlet for each of these screens and thus, for each single function required to accomplish a particular task. The “one portlet fits all” approach implies developing one single monolithic application which is, due to its complexity, hard to maintain, poorly scalable and, due to its non-modular character, difficult to reuse. However, this approach provides developers and screen-flow modelers with the highest control for guiding users through the flow. In contrast, the “one portlet per screen”-approach offers much higher flexibility and increases options for reusability tremendously. Hence, guiding users becomes less strict and less controllable which may increase the danger of erroneous navigation. Hence, either developers have to “hard-wire” portlets which may reduce flexibility or, users have to find out about the intended flow which may increase the risk for incorrect usage. In general, there is no single right answer for the “right” granularity which often leads to time consuming discussions and decisions depending on the actual scenario to be implemented.
There are several approaches for developing portal based workflows. Document US 2013/0152021 A1 discloses a method for providing workflow stages and integrated workflow stage visualization including displaying a detailed view of a workflow. The workflow may include a plurality of customizable stages. At least a first workflow stage is configured to contain a plurality of customizable workflow components and displaying them in a detailed view. Then, a selection of a stage view within the workflow may be received.
Document U.S. Pat. No. 8,271,541 B2 discloses a method for developing composite applications. A model architecture component can model a business rule utilizing at least one node in a hierarchical structure. A runtime engine can automatically create a complex, long running composite application based at least in part upon the hierarchical node structure such that the representative process segments of the application are involved by the business rule.